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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Railway 
Telecommunications (RT). 



Introduction 

The User-to-User Signalling Supplementary Service is widely used in the operation of GSM for Railways (GSM-R). 
The applications "Presentation of Functional Numbers" [i.2] and [i.3] and "Confirmation of High Priority Calls" [i.4] 
and [i.5] have been specified, implemented and tested in the framework of national GSM-R schemes. In defining 
layouts for the new features, DSD Alarm Notification, Alerting of a Controller and CHPC for enhanced Railway 
Emergency Call, care has been taken to ensure that existing implementations are not compromised or invalidated when 
laying out a framework for flexible further extension. For any such further extension, therefore, it is mandatory to 
define the use of UUIE in these various applications to avoid interoperability issues in the future. 
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Scope 



The present document defines the contents of the User-to-User Information Element when used in the GSM-R 
environment. This includes the basic EIRENE features Functional Addressing, Location Dependant Addressing, 
Confirmation of High Priority Calls (including, but not exclusively, REC and eREC) and Presentation of Functional 
Numbers. In addition the present document defines layouts for further features: Enhanced Presentation of Functional 
Numbers, Enhanced Location Dependent Addressing, Driver's Safety Device alarm. Plain Text Messages, Presentation 
of the Functional Number of the initiator of a Railway Emergency Call and Alerting of a Controller. Finally, the present 
document describes the requirements to be followed by network operators to ensure compatibility and interoperability if 
they wish to define specific fields for national and/or network use. The details of such fields are outside the scope of the 
present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 123 038 (V3.3.0): "Digital cellular telecommunications system (Phase 2+) (GSM); 

Universal Mobile Telecommunications System (UMTS); Alphabets and language- specific 
information (3G TS 23.038 Release 1999)". 

[2] ETSI TS 124 007 (V3.10.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); Mobile radio interface signalling layer 3; General 
aspects (3GPP TS 24.007 Release 1999)". 

[3] ETSI TS 100 933 (V8.6.0): "Digital cellular telecommunications system (Phase 2+); Voice Group 

Call Service (VGCS); Stage 2 (3GPP TS 03.68 Release 1999)". 

[4] ETSI TS 100 948 (V8.1.0): "Digital cellular telecommunications system (Phase 2+) (GSM); 

Group Call Control (GCC) protocol (GSM 04.68 Release 1999)". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] EIRENE SRS: "UIC Project EIRENE System Requirements Specification". 

NOTE: Available at UIC EIRENE Specifications . 

[i.2] MORANE F 10 T 6003 4: "FEES for Presentation of Functional Numbers to Called and Calling 

Parties". 

NOTE: Available at UIC GSM-R Normative Documents. 
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[i.3] MORANE F 12 T 6003 4: "FIS for Presentation of Functional Numbers to Called and Calling 

Parties". 

NOTE: Available at UIC GSM-R Normative Documents. 

[i.4] MORANE F 10 T 6002 5: "FEES for Confirmation of High Priority Calls". 

NOTE: Available at UIC GSM-R Normative Documents. 

[i.5] MORANE F 12 T 6002 5: "FIS for Confirmation of High Priority Calls". 

NOTE: Available at UIC GSM-R Normative Documents. 

[i.6] eLDA IRS (V5.0): "Interface Requirements Specification enhanced Location Dependent 

Addressing". 

NOTE: Available at UIC GSM-R Informative Documents. 

[i.7] 0-3 15 1-1.0 eREC specification. 

NOTE: Available at UIC GSM-R Informative Documents. 



[i.8] 0-3 152-1 .0 Definition and structure of eREC parameters. 

NOTE: Available at UIC GSM-R Informative Documents. 

[i.9] Void. 

[i.lO] Void. 

[i.ll] ETSI Directives. 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in the ETSI directives [i.ll] and the following 
apply: 

cab radio: radio and associated user and other interfaces installed in the cab of a locomotive and for use principally by 
the locomotive driver 

call type: prefix used to identify the type of user number dialled 

coach number: number assigned to an item of rolling stock on a permanent basis 

NOTE: The coach number may form a component of a functional number used to address users/systems on an 
item of rolling stock. 

controller: individual at a fixed location responsible for the conduct and co-ordination of some aspect of train 
operations 

NOTE: Also known as a dispatcher, in particular the term dispatcher is used in this context in ETSI specifications 
relating to the VGCS and VBS. 

dispatcher: individual at a fixed location responsible for the conduct and co-ordination of vehicle movements and 
operations 

NOTE: In railway operations, the dispatcher is usually known as a controller. 

driver's safety device: on-train system which monitors the alertness of the driver and provides warning and alarms to 
other systems as appropriate 
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engine number: number assigned to an item of traction stock on a permanent basis 



NOTE: The engine number may form a component of a functional number used to address users/systems on an 
item of traction stock. 

enhanced railway emergency call: railway emergency call with enhanced functionality to sub-divide the area covered 
by such a call 

NOTE 1 : Sub-divided areas which are covered by an eREC are used to include or exclude joining, crossing and 
parallel tracks and also shunting areas. 

NOTE 2: eREC allows discrimination of railway emergency calls in order to minimize production loss. 

functional addressing/numbering: term used to describe the process of addressing a call using a number representing 
the function a user is performing, rather than a number identifying the user's terminal equipment 

functional identity: full alphanumeric description of the function performed by a called or calling party within the 
functional numbering scheme, identifying them by function or role rather than by a specific item of radio equipment or 
user subscription 

NOTE: The functional identity can include characters and/or numbers. 

functional number: full number used within the functional addressing scheme to contact an end user/system by 
function or role rather than by a specific item of radio equipment or user subscription 

group call: call made to all members of a pre-defined group within a local geographical area 

NOTE: Only one member of the group may talk at any instant with all other group members listening only. 

international code: prefix used to identify an EIRENE network outside the network the in which the calling party is 
operating 

location dependent addressing: term used to describe the process of addressing a particular function (typically a 
controller) based on the current location of the user (typically a train) 

railway emergency call: call of the highest priority for informing drivers, controllers and other concerned personnel of 
a level of danger requiring all railway movements in a pre-defined area to follow specific operational procedures 

NOTE: Two types of railway emergency calls are defined: 

■ train emergency calls (for railway emergencies whilst not involved in shunting operations); 

■ shunting emergency calls (for railway emergencies whilst involved in shunting operations). 

train number: number given to a train by operational staff for a particular journey 

NOTE: A train number may form a component of the functional number used to address users or systems on a 
train. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ASCII American Standard Code for Information Interchange 

BCD Binary Coded Decimal 

CB S Cell Broadcast Service 

CHPC Confirmation of High Priority Call 

CT Call Type 

DSD Driver's Safety Device 

EIRENE European Integrated Railway radio Enhanced Network 

eLDA enhanced Location Dependent Addressing 

ePFN enhanced Presentation of Functional Number 

eREC enhanced Railway Emergency Call 

EC Function Code 

FEES Form Fit Functional Specification 
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FIS Functional Interface Specification 

FN Functional Number 

GC_REF Group Call Reference 

GPS Global Positioning System 

GSM-R Global System for Mobile-Rail 

HMI Human Machine Interface 

IC International Code 

IE Information Element 

MCC Mobile Country Code 

MNC Mobile Network Code 

MORANE Mobile Radio for Railway Networks in Europe 

MSC Mobile Switching Centre 

OTDI Originator-To-Dispatcher-Information 

PEN Presentation of Functional Number 

RFC Railway Emergency Call 

TLV Tag Length Value 

UIC Union Internationale des Chemins de fer 

UIN User Identifier Number 

UUI User-to-User Information 

UUIE User-to-User Information Element 

UUS User-to-User Signalling 

UUSl User-to-User Signalling Service 1 

VBS Voice Broadcast Service 

VGCS Voice Group Call Service 



General UUIE Format 



4.1 Encoding protocol and information capacity 

The general format of the User-to-User Information Elements used in GSM-R is shown in figure 1 . 
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Length of user-user contents = 'm + 1' 
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1 
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m Octets 



Figure 1 : General ETSI coding format for User-to-User Information Elements (UUIE) 

The maximum length of user-defined information (m octets in figure 1) is limited to 32 octets (35 octets for the overall 
maximum length of the UUIE) to ensure transparency through all mobile and fixed elements of a GSM-R network. 
Binary encoding should generally be used to maximize the data content in this limited space. This requires the "protocol 
discriminator" to be set to "User-Specific Protocol". 

< User-to-User protocol discriminator >: 00000000 User Specific Protocol. 

NOTE: In one special case, "Presentation of the Functional Identity of the Initiator of a Railway Emergency 
Call", the ETSI specifications for VGCS make necessary the use of a different encoding and protocol 
discriminator (see clause 6). 
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4.2 General encoding of the user defined content 

The UUIE provides a limited space of 32 information octets. Therefore an efficient and flexible coding scheme based 
on the "Tag-Length- Value" (TLV) structure is used. This coding scheme allows for easy and correct decoding of 
received information even when information not understood by the receiving application is mixed with the desired 
information. This scheme also supports the inclusion of multiple user information fields of variable lengths. The general 
structure is illustrated in figure 2. 
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Figure 2: Generic coding format for User-to-User Information Elements (UUIE) 
using user specific protocol in the GSM-R context 

The structure of Tag, Length, Value is repeated, as many times as there are tags in the message and enough room for 
them. This is the TLV structure. Restrictions on the order of TLV tags is as defined in clause 7.LL 



4.3 Definition of tag values 



The number of different tags for UUIE content complying with the TLV structure is limited to 255 where the tag range 
to 127 is reserved for international use and the range 128 to 255 is reserved for national use. 

The tags that are defined for international use are listed in table 1 . 

Table 1 : Identification of GSM-R specific tags for international use 



Tag Value 


Feature 


2 


Acknowledgement by Receiver of a High Priority Call and response from device 
accepting the acknowledgement 


3 


Acknowledgement by Initiator of a High Priority Call 


4 


eREC extension for acknowledgement of a High Priority call 


5 


Presentation of Functional Number 


6 to 8 


enhanced Location Dependent Addressing 


9 


ePFN Information 


10 


User specific plain text according to alphabet indicator 


11 


DSD Alarm Notification 


12 


Alerting of a Controller Notification and Response 
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Definition of individual tag contents 



This clause defines the content of each of the tags Hsted in table 1 . The tags may be combined with other tags in specific 
applications, and such uses are described in clause 7. Because tags may be combined, the illustrations in this clause only 
contain the tag definition and do not illustrate the complete UUIE structure and content. Clause 7 contains complete 
examples of that kind. 

5.1 Presentation of functional number tag 

According to [i.2] and [i.3], the Functional Number (FN) is always transferred in the UUSl as an International FN, that 
is: 

FN = IC + CT + UIN + FC 

This tag can be included in any allowed call control message where it is required to transfer the FN of the sending party 
to the other party in the call. The general layout of the PFN tag is given in figure 3. 
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Tag representing Presentation of Functional Number = '05' 

1 1 , 1 1 1 1 1 


Octet 1 


Functional number length = m octets - 2 octets 


Octet 2 


BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 




BCD-coded FN digit #3 


Octet 4 








BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 



Functional 
Number 



NOTE 1 : The FN length field specifies the number of octets present to carry the FN. Each digit of a FN is encoded 
as a BCD digit (one nibble). The first FN digit is in bits 1 to 4 and the next digit is in bits 5 to 8 of octet 3 of 
the tag; the following digit is in bits 1 to 4 of next octet and so on. If the FN consists of an odd number of 
digits, then the last half octet (bits 4 to 7) of the FN should contain "OxF" as a filler. Therefore "OxF" can 
never be a valid digit within the FN. 

NOTE 2: The hexadecimal value "OxF" represents the binary value of 4 bits, all set to "1 ". 

Figure 3: General Format of PFN Tag Content 

Octets consisting of two half octets, both set to "OxF", shall not be used in PFN tags as a filler; only octets containing 
valid BCD digits, or a single "OxF" nibble shall be included. If no valid FN is available for transmission, then a PFN tag 
encoded as shown in figure 4 shall be used. 



l: 
























Tag representing Presentation of Functional Number = '05' 

1 1 , 1 1 1 1 1 


Octet 1 


Functional number length = 


Octet 2 



Figure 4: PFN Tag Content to Indicate "No FN Avaiiable" 



5.2 Confirmation of High Priority Calls tags 

The procedure for the Confirmation of a High Priority Call, including RFC and eREC, is defined in [i.4] and [i.5]. 
UUS 1 tags are used by the mobiles involved in the call and also by the network device that is responsible for collecting 
the confirmation messages. The tags involved are defined below. 
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5.2.1 CHPC tag definition for mobile device 






/ 



















Tag representing Confirmation of High Priority Call = '02' or '03' 

1 1 , 1 1 1 1 X 


Octet 1 


CHPC message length = 13 octets 


Octet 2 


T_DUR low octet 


Octets 3-5 
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Octets 6-9 
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T_REL high octet 


PL_CALL 


Octet 10 


CAUSE 


Octet 11 


GC_REF digit#2 


GC_REF digit#1 


Octets 
12-15 


GC_REF digit#4 


GC_REF digit#3 


GC_REF digit#6 


GC_REF digit#5 


GC_REF digit#8 
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of call 



Relative time 
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Figure 5: CHPC tag content for mobile device 

The tag content is identical in structure for both the call initiator and the call recipients and is illustrated in figure 5, only 
the tag value differs for the two cases. The information is included in a SETUP message. The fields of the message have 
the following interpretation: 

• T_DUR: A 24-bit unsigned integer specifying the duration of the call in units of 100 ms. 

• T_REL: A 32-bit unsigned integer specifying the interval between the end of the call and the transmission of 
the confirmation message in units of 100 ms. 

• PL_CALL: An 8 bit value giving the priority level of the call as follows (this is a general encoding and in 
practice value 0x05 is the one usually to be employed): 

0x00 no priority specified in call; 

0x01 eMLPP priority of 4 (Railway Information); 

0x02 eMLPP priority of 3 (Railway Operation); 

0x03 eMLPP priority of 2 (Public Emergency/Group Calls); 

0x04 eMLPP priority of 1 (Command and Control); 

0x05 eMLPP priority of (Railway Emergency). 

• CAUSE: An 8 bit value giving the reason for termination of the call as follows: 

0x00 no error; 

Bits #1 to 4 (least significant bits) system errors; 

Bit #1 mobile was powered off when receiving (power fail); 

Bit #2 call was interrupted due to radio link error; 
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Bit #3 reserved; 

Bit #4 reserved; 

Bits #5 to 8 (most significant bits) user actions; 

Bit #5 call was left on user command; 

Bit #6 reserved; 

Bit #7 reserved; 

Bit #8 reserved. 

• GC_REF: A 4-octet value giving the group call reference of the call [3], encoded as 8 nibbles with each nibble 
being a BCD value representing one digit of the group call reference. 

If this tag is being sent as part of the confirmation sequence of an eREC that the mobile station determined it should not 
join then the values of some of the above fields shall be set to specific, non-intuitive, values as follows: 

T_DUR: A 24-bit unsigned integer of value 00 00 00. 

T_REL: A 32-bit unsigned integer giving the interval between the decision not to join the call and the 
transmission of the confirmation message in units of 100 ms. 

PL_CALL: An 8 bit value giving the priority level of the call - unchanged from basic usage given above. 

CAUSE: An 8 bit value giving the reason for termination of the call - always 0x00 (no error). 

GC_REF: A 4-octet value giving the group call reference of the call - unchanged from basic usage given 
above. 

5.2.2 CHPC tag definition for collecting network device 

The network device which collects the confirmation messages is required to indicate back to the sending mobile device 
whether the information has been successfully received and stored or not. The tag is included in a 
RELEASE_COMPLETE message which shall have the release cause value of "Normal Call Clearing". The tag content 
is illustrated in figure 6. 



Tag identifying Confirmation of High Priority Call = '02' 

J \ I ^ L 



Octet 1 



ACK/CAUSE 

_>^ I x_ 



Octet 2 



Figure 6: CHPC tag layout for collecting network device 

NOTE: This is the only tag where there is no length field following the tag identity octet in the UUSl content. 

The tag value is the same as that used by a receiving mobile, but has a completely different content which 
is not ambiguous, because the direction of the information defines the correct context. The ACK/CAUSE 
values are listed below: 

0x00 ACK no error 

0x01 NACK-1 error, repetition should take place 

0x80 NACK-2 fatal error, NO repetition to take place 

0x02 to 0x7f reserved for internal use 

0x8 1 to Oxff reserved 
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5.2.3 CHPC eREC extension tag definition for mobile device 

In the framework of eREC service, this tag is used in addition to the tags defined in clause 5.2.1 to transfer eREC 
specific data. 



























Tag representing eREC CHPC = '04' 

1 , 1 1 








Octet 1 


eREC CHPC length = 2 octets 


Octet 2 
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Sector ID 
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eREC Join 
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Validation status 

X 1 X 


Update method 

X 1 X 1 X 
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Figure 6a: eREC CHPC tag content for mobile device 

The tag content is identical in structure for both the call initiator and the call recipients and is illustrated in figure 6a. 
The circumstances under which this tag is included as part of the CHPC process is described in [i.4] and [i.5]. An 
explanation of the purpose of the fields included in the tag is provided in [i.7] and [i.8]. The information shall be 
included in a SETUP message. The fields of the message shall have the following interpretation: 

• Sector ID: Coded in 9 bits, each bit representing one eREC sector ID in the range [1..9]. Setting a bit to "1" 
means the corresponding sector ID was active at the time of the call being acknowledged. 

Octet 3 contains sector IDs 1 to 8, with the least significant bit giving the state of sector ID 1 and the most 
significant bit giving the state of sector ID 8. The least significant bit of octet 4 gives the state of sector ID 9. 

In the case of CHPC for the initiation of an eREC this field shall include the current active sector ID for call 
initiation. Consequently it shall one and only one active sector ID, or no active sector ID if the mobile station 
is in eREC standby mode. 

In the case of CHPC for the reception of an eREC, this field shall include all the active sector IDs for call 
reception, or no active sector ID if the mobile station is in eREC standby mode. 

• Update method: Coded in 3 bits in octet 4 with bit 2 being the least significant. This field gives the method 
used for the last eREC sector ID update performed by the mobile station as follows: 

OOOB: No update performed since last eREC registration; 

00 IB: Last update performed from the mobile station HMI; 

01 OB: Last update performed using USSD update method; 

01 IB : Last update performed using balise update method; 

All other values are reserved for future use and shall not be used until defined. 

• Validation status: Coded in 2 bits in octet 4 with bit 5 being the least significant. This field gives the status of 
the sector ID validation(s) performed by the mobile station since the last sector ID update as follows: 

OOB: No validation performed since the most recent eREC sector ID update; 

OIB: All validations performed successfully since the most recent eREC sector ID update; 

lOB: At least one validation has failed since the most recent eREC sector ID update (this means that 
at least one sector ID provided in the most recent sector ID update has been deactivated by the validation 
process); 



IIB: 



Reserved for future use - shall not be used. 



• eREC Join: Coded in bit 7 of octet 4 with the value "0" meaning that the call was not joined by the mobile 
station and the value " 1 " meaning that the call was joined. The value " 1 " shall be used by the eREC call 
initiator. 
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5.3 Enhanced presentation of functional number 

In some situations it has been identified that presenting only the FN of a subscriber may not provide sufficient 
information for the other party/parties in the call. A tag has therefore been defined which allows for presentation of 
three further pieces of information, all of which are optional. These are defined in table 2. 

Table 2: Information content of enhanced PFN 



Position 


Contents 


Status 


Comment 


1 


ASCII Text Information (e.g. "Nice Signaller 1") 





ePFN 
Information 


2 


Country Information 





3 


Call Type 





NOTE: = optional information 



The definition of the overall tag structure is shown in figure 7. In order to make efficient use of the limited space, 
CSN. 1 coding according to [2] is used in ePFN information field. The encoding of the three optional fields is defined in 
table 3. 



ePFN 
Information 















2 


1 




Tag representing extended PFN = '09' 

1 1 1 , 1 1 





1 


Octet 1 


extended PFN lengtii = m octets - 2 octets 


Octet 2 


1 

ePFN Information 

1 




Octet 3-m 



Figure 7: Overall structure of ePFN tag 



Table 3: CSN.1 definition of ePFN information content 



<ePFN Info : : = 

{O I 1 <Length of ASCII string : bit (5)> <IA5 ASCII octet string>} 
jo I 1 <MCCdigitl : bit(4)> <MCCdigit2 : bit(4)> <MCCdigit3 : bit(4)> 

<MNCdigitl : bit(4)> <MNCdigit2 : bit(4)> <MNCdigit3 : bit(4)>} 
{0 I 1 <CT>} 
{<spare bits>} ; 

<Length of ASCII string> indicates the number of octets in the <IA5 ASCII octet string>. 

<IA5 ASCII octet string > ::= <octet : bit (8) * (val (Length of ASCII string) )>; 

<CT> ::= <digit2 : bit(4)> <digitl : bit(4)>; 

<spare bits> ::= <null | <spare bits> {<bit> = 0} -- number of bits added is selected to 

ensure "ePFN Info" occupies the minimum 
quantity of octets, padded with "0" bits 
in any unused locations at the end ; 



Examples of the encoding defined in table 3 are provided in clause 7.3. 

5.4 Presentation of text strings 

According to UUI specification the IE can contain a text string composed of IA5 characters, but this requires use of the 
appropriate User-to-User Protocol Discriminator value. There are also difficulties if characters from different language 
sets are to be transferred. Finally, the use of the raw IA5 encoding scheme is reserved for presentation of decompressed 
OTDI for emergency calls, as described in clause 6.3. 

If an application requires to send plain text in a UUIE then this tag shall be used. This tag contains the plain text 
preceded by the alphabet indicator as illustrated in figure 8. The alphabet indicator is selected according to the CBS data 
coding scheme [1]. 
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Plain 
Text 



8 


7 




5 


4 
















Tag representing Plain Text = "10' 

1 1 1 1 1 1 1 


Octet 1 


Plain text length = m octets - 2 octets 


Octet 2 


X 


X 


Alphabet Indicator 

X 1 X X 1 X 1 X 1 X 


Octet 3 




Plain Text 


Octets 4-m 



Figure 8: Coding of piain text tag 



5.5 Transfer of train position 



The UIC ad-hoc working group on enhanced Location Dependent Addressing (eLDA) has defined a mechanism for 
transferring the location of a train to the fixed GSM-R infra- structure during call setup. A full discussion of this topic 
can be found in [i.6]. This mechanism was originally devised so that a call might be routed with greater precision than is 
possible with the basic cell-based routing specified within EIRENE, but it also finds uses in providing a static indication 
of a train's position, such as when indicating a DSD alarm condition. The transfer mechanism is based on the use of 
UUSl. An example of the proposed tag is given in figure 9. This example represents the transfer of the following 
position: (Further details may be found in [i.6]). 

1) Latitude: 89 59 59.99 S. 

2) Longitude: 179 59 59.99 East. 

3) Height: 1 234 m. 

4) Speed: 210 Km/hr. 

5) Heading: 120°. 

6) Elapsed time: 2 012 s. 

7) Distance: 95 000 m. 

8) Scale: 10 m. 
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GPS 
Information 



Odometry Information 



1 


Tag representing eLDA information = '06' 

, 1 1 1 1 1 





Octet 1 


1 


Location data length (octets) 

0,0,1,1,1 





Octet 2 


1 , 


1,1,0,0,1 


1 


Octets 


1 1 1 


1 1 ..„=L..^. 1 1 1 1 





1 


Octet 4 


1 1 1 





1,1,0,1 


1 


Octets 


1 1 1 





1,0,1,1 





Octet 6 


, 1 


1 1 1 L onditudc 1 1 1 1 





1 


Octet? 


1 1 1 


0,1,1,1, 





1 


Octets 


1 , 


1,1,1,1,0 





Octet 9 


1 1 


, 1 ^^9ht 0,0,1 


1 


Octet 10 


, 1 


1 , 


Speed 

0,1, 





1 


Octet 11 


Soeed (continue^d) 


n n -1 Heading 

0,0,1,1, 








Octet 12 


1,1,1 


Elapsed time 

1,1,0,1 


1 


Octet 13 


1 , 





1,0,0,1 





Octet 14 


1 








^'^*f"- 1,1,1 





Octet 15 





1 ^T 


1 , 1 , ^Pf- , 1 


1 


Octet 16 



Figure 9: Example of eLDA information tag 



5.6 



Notification DSD alarm condition 



When a driver becomes incapacitated it is important to notify the responsible dispatcher of the situation so that the 
necessary steps to ensure safety can be taken. The method for providing the notification is by the use of a special UUSl 
tag. The content of this tag is defined in figure 10. 



Engine 
Number 



Tag representing Presentation of DSD Alarm = '11' 



_L 



_L 



_L 



DSD Alarm length = 4 octets 



EN digit #2 



EN digit #1 



EN digit #4 



EN digit #3 



EN digit #8 



EN digit #7 



Octet 1 



Octet 2 



Octet 3 



Octet 4 



Octet 5 



Octet 6 



Figure 10: DSD alarm tag layout 

The content of the tag is the 8 digits of the locomotives engine number as defined in EIRENE SRS [i.l]. Each digit is 
represented by its BCD value in one nibble. The engine number has a fixed length with an even number of digits, so no 
nibble fill character is needed. 

5.7 Notification of a request to alert a controller 

At times during a shunting group call it is required to request that a controller that had previously left the call rejoin the 
call to respond to a query from a member of the call. The method for providing the request, and the response from the 
recipient's equipment, is by use of a special UUSl tag. The content of the tag is defined in figure 11. 
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Tag representing Alerting of a Controller = '12' 

|0|0|0|1|1|0|0 


Octet 1 





Alerting of a Controller length = 4 octets 

|0|OiO|0|1|0|0 


Octet 2 


Group Call Area digit #2 Group Call Area digit #1 


Octet 3 


Group Call Area digit #4 Group Call Area digit #3 


Octet 4 


Group ID digit #1 Group Call Area digit #5 


Octet 5 


Group ID digit #3 Group ID digit #2 


Octet 6 



Group Call 
Reference 



Figure 1 1 : Alerting of a controller tag layout 

The content of the tag is the 8 digits of the Group Call Reference [3] of the call. Each digit is represented by its BCD 
value in one nibble. The Group Call Reference has a fixed length with an even number of digits, so no nibble fill 
character is needed. The order of the digits is the same as in other tags where this type of information is encoded. 



Transfer of functional number of initiator of railway 
emergency call 



6.1 



Introduction 



When a network and the mobiles using it employ the IMMEDIATE SETUP 2 message to initiate a REC or eREC the 
originator's FN shall be placed in the compressed OTDI Information Element of that message. This clause fully 
specifies the parts of the FN information to be inserted in that information element. Furthermore, the compressed OTDI 
IE is only applicable to IMMEDIATE SETUP 2 and this call setup message is unavailable in the fixed network. 

The MSC will convert the information into decompressed OTDI for delivery by means of UUSl to other subscribers of 
the REC/eREC within a conventional SETUP message. This conversion is specified in [4]. Clause 7.2 contains an 
example of the content of the compressed OTDI and decompressed UUSl resulting. 

NOTE: The format of the decompressed UUIE does not conform to the general GSM-R UUIE format described 
in clause 4. 



6.2 Compressed OTDI encoding 



This IE provides 40 bits for the information field of the user. [4] states the following about the encoding of these bits: 

• "The compressed otdi information element specifies an integer N in 40 bit binary representation; bit 8 of 

octet 1 is the most significant bit and bit 1 of octet 5 is the least significant bit. The integer denotes compressed 
originator-to-dispatcher information" . 

Consequently it is not possible to consider using the UUS 1 encodings described elsewhere in the present document. The 
40 bit integer can represent a decimal number in the range to 1 099 511 627 775, for practical purposes, in relation to 
functional numbers, the maximum range is to 999 999 999 999 (i.e. 12 digits). The maximum length of a FN, 
including International Code is 15 digits (coach number), therefore to encode as compressed OTDI, the International 
Code is omitted. 

The omission of the International Code does not generally lead to ambiguity, since the FN being transferred will usually 
be a CT2 train number. This will be registered in the same country as that in which the REC/eREC originates. At the 
international border the IC is assumed to be the same as the network in which the REC/eREC originates. This is because 
the train will register its functional number immediately after attaching to a new network. 

In cases where no train number is available, an engine number will be sent. These are always registered in the "home" 
network of the mobile and the International Code cannot be derived from that of the group call reference. 
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6.3 Conversion of compressed OTDI into UUIE 

The MSC shall convert the received compressed OTDI into UUIE of the UUS 1 according to the following definition 
found in [4] : 

• "The corresponding decompressed originator-to-dispatcher information is given by the following attributes: 

User-user protocol discriminator: IA5 characters. 

User-user information: The user-user information is a string of 12 digits which are the decimal 
representation of the integer N with leading zeros. Each digit after decompression is coded in one octet. 
The bits 1 to 7 are used for the coding of the IA5 character, and bit 8 is coded as '0'." 

This procedure does not make any provision for railway- specific interpretation, such as reconstruction of the 
International Code. The railway application within the device which receives the call is responsible for performing this 
action. 



7 Examples of use 

7.1 Examples according to general UUIE format 

7.1 .1 Presentation of functional number 

When the PEN tag is present in the UUIE in a GSM-R application, it shall always be the first such tag. This is to ensure 
compatibility with applications that do not understand the more complex tags such as the train position tag. There is a 
specific exception to this rule in respect of the CHPC application, and this is explained in clause 7.1.2. 

7.1 .2 Confirmation of High Priority Calls Application 

Two alternative arrangements of the tags in the UUIE are permissible for the CHPC application when either the mobile 
station or its serving network are not eREC capable. Both contain a PEN tag and a CHPC tag and are referred to as 
"Eormat A" and "Eormat B". There is no preference for which shall be used by any device sending such a confirmation 
message, and the capturing device shall be able to accept either format without error. The two alternative layouts are 
shown in figures 12 and 13 respectively. 

When both the mobile station and its serving network are eREC capable, the CHPC eREC extension tag defined in 
clause 5.2.3 shall be included in the information sent by the mobile station. The mobile station can utilize either 
"Eormat A" or "Eormat B", but the CHPC eREC extension tag shall be placed after the non-eREC CHPC tags (that is it 
shall be the third tag in the UUIE). An example of the confirmation of an eREC based on "Eormat B" is shown in 
figure 13 a. 
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8 












2 


1 








User-to-user lEI 


Octet 1 


UUIE J 
Header 1 


Length of user-user contents 


Octet 2 




User-to-user protocol discriminator 

0|0|0|0|0|0|0|0 


Octet 3 




Tag representing Confirmation of High Priority Call = "02" or "03" 

0|0|0|0|0|0|1 |X 


Octet 1 




CHPC message length = 13 octets 


Octet 2 




>- 


T_DUR low Octet 


Octets 3-5 


Duration J 
of call ] 


T_DUR mid Octet 




T_DUR high Octet 




T_REL low Octet 


Octets 6-9 


Relative time 
of termination 


T_REL mid-low Octet 


T_REL mid-high Octet 




T_REL high Octet 


Priority level C 
of call \ 


PL_CALL 


Octet 10 


Cause of T~ 
termination \^ 


CAUSE 


Octet 11 






GC_REF digit#2 


GC_REF digit#1 


Octets 
12-15 


Group call 
reference 


GC_REF digit#4 


GC_REF digit#3 


GC_REF digit#6 


GC_REF digit#5 




GC_REF digit#8 


GC_REF digit#7 




Tag representing Presentation of Functional Number = '05' 

0|0|0|0|0|1 |0|1 


Octet 1 




Functional number length = m octets - 2 octets 


Octet 2 






BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 






BCD-coded FN digit #3 


Octet 4 


Functional 
Number 










BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 



Figure 12: CHPC "Format A" tag layout 



ETS\ 



20 



ETSI TS 102 610 VI .3.0 (2013-01) 



UUIE 
Header 



Functional 
Number S 



Duration 
of call 



Relative time 
of termination 



Priority level 

of call 

Cause of 

termination 



Group call 
reference 



8 












2 


1 




User-to-user lEI 


Octet 1 


Length of user-user contents 


Octet 2 


User-to-user protocol discriminator 

0|0|0|0|0|0|0|0 


Octet 3 


Tag representing Presentation of Functional Number = '05' 

0|0|0|0|0|1 |0|1 


Octet 1 


Functional number length = m octets - 2 octets 


Octet 2 


BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 




BCD-coded FN digit #3 


Octet 4 








BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 


Tag representing Confirmation of High Priority Call = '02' or '03' 

0|0|0|0|0|0|1|X 


Octet 1 


CHPC message length = 13 octets 


Octet 2 


T_DUR low octet 


Octets 3-5 


T_DUR mid octet 


T_DUR high octet 


T_REL low octet 


Octets 6-9 


T_REL mid-low octet 


T_REL mid-high octet 


T_REL high octet 


PL_CALL 


Octet 10 


CAUSE 


Octet 1 1 


GC_REF digit#2 


GC_REF digit#1 


Octets 
12-15 


GC_REF digit#4 


GC_REF digit#3 


GC_REF digit#6 


GC_REF digit#5 


GC_REF digit#8 


GC_REF digit#7 



Figure 13: CHPC "Format B" tag layout 
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UUIE 
Header 



Functional 
Number S 



Duration 
of call 



Relative time 
of termination 



Priority level 

of call 

Cause of 

termination 



Group call 
reference 



eREC 

CHPC 

data 



8 


/ 
















User-to-user lEI 


Octet 1 


Length of user-user contents 


Octet 2 





User-to-user protocol discriminator 

0|0|0|0|0|0|0 


Octet 3 





Tag representing Presentation of Functional Number = '05' 

1 1 , 1 1 1 1 1 


Octet 1 


Functional number length = m octets - 2 octets 


Octet 2 


BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 




BCD-coded FN digit #3 


Octet 4 








BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 





Tag representing Confirmation of High Priority Call = '02' or '03' 

0|0|0,0|0|1|X 


Octet 1 


CHPC message length = 13 octets 


Octet 2 


T_DUR low octet 


Octets 3-5 


T_DUR mid octet 


T_DUR high octet 


T_REL low octet 


Octets 6-9 


T_REL mid-low octet 


T_REL mid-high octet 


T_REL high octet 


PL_CALL 


Octet 10 


CAUSE 


Octet 1 1 


GC_REF digit#2 


GC_REF digit#1 


Octets 
12-15 


GC_REF digit#4 


GC_REF digit#3 


GC_REF digit#6 


GC_REF digit#5 


GC_REF digit#8 


GC_REF digit#7 





Tag representing eREC CHPC = "04" 

0|0|0|0|1 |0|0 


Octet 1 


eREC CHPC length = 2 octets 


Octet 2 








Sect 

1 


or ID 

0,0,1 





Octet 3 


Spare 




eREC Join 

1 


Validation status 

, 1 


Update method 

0,1,0 


Sector ID 

1 


Octet 4 



NOTE 1 : In this figure the eREC CHPC uses the following values as examples: 

Sector IDs 2 and 9 are active 

The USSD update method was employed most recently 

All validations of sector ID have been successful since the last sector ID update 

The call was joined. 
NOTE 2: No example values for the other fields of the CHPC message are included. 

Figure 13a: CHPC for eREC based on "Format B" tag layout 
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7.1 .3 Enhanced presentation of functional number 

When the ePFN tag is used to provide the extra information that it carries, it shall always be used in conjunction with 
the normal PFN tag. To avoid interworking issues with applications that do not understand the ePFN tag the PFN tag 
shall be placed first in the UUIE. The required arrangement of the tags is shown in figure 14. 



UUIE 
Header 



Functional 
Number 



ePFN 
Information 















2 


1 




User-to-user 1 El 


Octet 1 


Length of user-user contents 


Octet 2 





User-to-user protocol discriminator 

0|0|0|0|0|0|0 


Octet 3 





Tag representing Presentation of Functional Number = '05' 

0,0,0,0,1,0,1 


Octet 1 


Functional number length = m octets - 2 octets 


Octet 2 


BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 




BCD-coded FN digit #3 


Octet 4 












BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 





Tag representing extended PFN = '09' 

, , , 1 1 1 1 1 


Octet 1 


extended PFN length = n octets - 2 octets 


Octet 2 




1 

ePFN Information 
1 




Octet 3-n 



Figure 14: ePFN tag layout 
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7.1 .4 Transfer of train position for eLDA 



When train position is being provided by an on-train system, such as GPS, for use in eLDA it shall be transferred to the 
fixed infra- structure in the UUIE of the SETUP message initiating the call. The train position tag shall always be used 
in conjunction with the PFN tag. As already stated, the PFN tag shall be placed first in the UUIE. The arrangement is 
shown in figure 15. If train-based eLDA is being used then the use of ePFN in the same SETUP may be impossible 
because of the limited length of the UUIE. If there is sufficient space for both the ePFN and train position tags then they 
may be placed in either order following the PFN tag. 



UUIE 
Header 



Functional 
Number 



GPS 
Information 









6 


5 


4 


3 


2 


1 




r 


User-to-user lEI 


Octet 1 


Length of user-user contents 


Octet 2 





User-to-user protocol discriminator 

0,0,0,0,0,0 





Octet 3 







Tag representing Presentation of Functional Number = '05' 

1 1 , 1 1 1 


1 


Octet 1 




Functional number length = m octets - 2 octets 


Octet 2 




BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 




BCD-coded FN digit #3 


Octet 4 








BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 







Tag representing eLDA information = '06' 

0,0,0,0,1,1 





Octet 1 







Location data length (octets) 

0,0,0,1,1,1 





Octet 2 


v_ 


1 1 1 1 1 1 1 1 1 1 


1 


Octet 3 


1 1 1 1 1 1 ..„=L.... 1 1 1 1 


1 


Octet 4 


1 1 1 1 


i_aiuiuuc 

1,1,0,1 


1 


Octets 


1 1 1 1 


1,0,1,1 





Octet 6 


1 1 1 1 


1 L onditudc 1 1 1 1 


1 


Octet? 


1 1 1 1 


1 1 1 1 1 1 


1 


Octets 


1 1 1 1 


1,1,1,0 





Octet 9 





1 1 


1 ""^ 


^•^'0,0,1 


1 


Octet 10 


, 1 


1 





, 1 ^^ 


1 


Octet 11 


Soeed (continued) 





, 1 "^^^ 1 , 





Octet 12 


1 1 1 1 1 


Elapsed time 

1,1,0,1 


1 


Octet 13 


1,0,0 


1,0,0,1 





Octet 14 


1 


, 


^'^*f"^^ 1,1,1 





Octet 15 





1 =-'" 


1 1 1 1 ^Pf'" 1 1 


1 


Octet 16 



Odometry Information 



Figure 15: Arrangement of tags for train-based eLDA 

7.1 .5 Notification of a DSD alarm condition 

The requirement from EIRENE is to transfer the train number, engine number and train location (optional). This can be 
achieved by using a combination of three existing tags: the PFN tag, the train position tag and the DSD tag. The layout 
for the combined use of these tags is given in figure 16. In keeping with the flexibility offered by the encoding scheme, 
the train position and DSD tags can be placed in the either order after the PFN tag. Receiving applications shall be able 
to interpret either sequence. There is no space left for use of the ePFN tag in this application. 
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In this application the PFN tag would normally include the train number and the driver function code of the engine 
detecting the alarm, but would be coded as "No FN Available" as specified in figure 4 if no train number were 
registered. No special function code for a DSD alarm is required. Note that the notification is not to result in a 
connected call. Once the information has been captured by the receiving application, the call should be rejected using 
DISCONNECT or RELEASE_COMPLETE. No response UUIE tag is defined or required for this appHcation. 
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User-to-user protocol discriminator 

1 1 1 1 1 





Octet 3 





Tag representing Presentation of Functional Number = '05' 

1 1 , 1 1 1 


1 


Octet 1 


Functional number length = m octets - 2 octets 


Octet 2 


BCD-coded FN digit #2 


BCD-coded FN digit #1 


Octet 3 
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Octet 4 








BCD-coded FN digit #p or $F 
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Octet m 





Tag representing eLDA information = '06' 
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Tag representing Presentation of DSD Alarm = '11' 

1 1 1 1 1 1 1 


1 


Octet 1 


DSD Alarm length = 4 octets 


Octet 2 


EN digit #2 EN digit #1 
EN digit #4 EN digit #3 


Octet 3 


Octet 4 


Octet 5 


EN digit #8 EN digit #7 


Octet 6 



Figure 16: Example of combined tag usage for DSD 
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7.1 .6 Notification of request to alert a controller 

The functionality "Alerting of a controller" shall be realized by transfer of a UUIE from the mobile station to the 
dispatcher terminal in the SETUP message. The tags involved are shown in figure 17. 

Note that the notification may result in a connected call or may result in the call being rejected after capturing of the 
transferred information; this behaviour is dependent on the national implementation. 

If the call is connected then normal call signalling shall be used, with the functional number of the recipient being 
returned as defined in [i.2]. 

If the call is rejected then once the information has been captured by the receiving application, the call shall be released 
immediately using RELEASE_COMPLETE or DISCONNECT message in a similar fashion to that specified for the 
CHPC application. The message shall contain a UUIE which carries the functional number of the dispatcher and the 
received alerting of a controller tag. 
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BCD-coded FN digit #p or $F 


BCD-coded FN digit #p-1 


Octet m 


Tag representing Alerting of Dispatcher = '12' 

0|0|0|0|1|1|0|0 


Octet 1 


Alerting Dispatcher length = 4 octets 

0|0|0|0|0|1|0|0 


Octet 2 


Group Call Area digit #2 Group Call Area digit #1 


Octet 3 


Group Call Area digit #4 Group Call Area digit #3 


Octet 4 


Group ID digit #1 Group Call Area digit #5 


Octet 5 


Group ID digit #3 Group ID digit #2 


Octet 6 



7.2 



Figure 17: Arrangement of tags for the alerting of a controiler process 

Example of transfer of functional nunnber of initiator of a 
railway emergency call 



The following example shows the format of compressed and decompressed OTDI which is used for the transfer of the 
functional number of the initiator of a railway emergency call. 

A cab radio is registered as lead driver of train with train number 12345 in a GSM-R network with International 
Code 069. This cab radio has therefore registered with the functional number 06921234501. The number to be 
transferred in the compressed OTDI is 21234501 which converts to the hexadecimal value 0x0001440345. On the air 
interface (in the IMMEDIATE SETUP2 message), these octets are represented as shown in figure 18. 
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Figure 18: Compressed OTDI encoding example 

The MSC converts the compressed OTDI octets back into the 12 digit integer 000021234501 which are represented in 
the UUSl IE shown in figure 19. 
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Figure 19: Example of expansion of compressed OTDI 
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7.3 Examples of encoding of ePFN tag 

The example shown in figure 20 is the encoding of the ePFN tag when it contains only the 3 character string "ABC". 
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Figure 20: Example 1 of enhanced Presentation of Functional Number 

The example shown in figure 21 is the encoding of the ePFN tag when it contains no text, but does contain the network 
identity "239 31". No Call type is present so 5 spare bits shall be added to ensure that a complete quantity of octets are 
defined. 
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Figure 21 : Example 2 of enhanced Presentation of Functional Number 
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